home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Aug 89 / X0065-?Memory Management-Aug89 < prev    next >
Encoding:
Text File  |  1989-08-22  |  1.7 KB  |  44 lines  |  [TEXT/GEOL]

  1. Item    1236020                         16-Aug-89        14:06
  2.  
  3. From:   AU0008                          Kopfwerk EDV SW Entwicklung
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    ?Memory Management
  8.  
  9. Hi TMAWorld = OBJECT(TMacApp),
  10.  
  11. I have problems to understand the memory management of MacApp and hope anybody
  12. could give me an answer to my questions:
  13.  
  14. 1. Is it possible to see in the MacApp debugger with the "Heap" command and the
  15. "Information" subcommand the amount of memory my objects uses? (espec. I want
  16. to test after closing a window or document if all my objects freed correctly
  17. and doesn´t waste any memory).
  18. The number of masterpointers seems not to give this information. Testing with
  19. "DemoDialogs" and opening and closing a window with "ViewsByTempl" leads to the
  20. following list of masterpointers: 603, 578, 577, 576, 575,…
  21. Why they are not constant? Is the state before I open a window not the same as
  22. after closing? Can an application run out of mem if the user repeatedly creates
  23. and frees an object?
  24.  
  25. 2. If you go low in memory the debugger says in heap informations:
  26. e.g. RESERVES   code = 306100 (low: 9628)   low space = 4096 (OK) …
  27. What does this "low: <number>" mean? Does it mean the amount of loaded
  28. resources reached 306100 + 9628 = 315728 bytes?
  29.  
  30. 3. What is "Needed reserve handle size = 41788" in the "TEMP SPACE" block?
  31.  
  32. 4. We have a high water mark for temporary memory. Does the same exist for
  33. permanent mem? Or could objects use all other free mem until they need the low
  34. space reserve?
  35.  
  36. Any help is
  37.  
  38. Tommi GESSL, KOPFWERK SW Dev.
  39.  
  40. ps: I think it is a good idea to have in the documentation a list of all heap
  41. information fields the debugger generates with their meaning.
  42.  
  43.  
  44.